Random numbers are often used in generating appropriate security parameters in a computer system. In some computer systems, entropy is added to a system that generates random numbers in order to generate differing sequences of random numbers. Entropy is a measure of the uncertainty associated with a random number. Further, entropy is a useful measurement for data used in seeding a random number generator, wherein typically, a high level of entropy leads to a stronger random number generator.
Often, data with a high level of entropy is a scarce resource. For example in some systems, high entropy data requires time to gather; e.g., by monitoring a network or disk. This means that if there is a demand for high entropy data there can sometimes be a delay whilst data is gathered to meet the demand.
Generally speaking, server virtualization describes a software abstraction that separates a physical resource and its use from the underlying physical machine. Most physical resources, such as processors, storage devices, and network adaptors, can be abstracted and provisioned as virtualized entities.
Virtual machines (VMs) play a central role in server virtualization. A VM is a virtualization of a physical machine and its hardware components. A VM typically includes a virtual processor, a virtual system memory, and various virtual devices. A single physical machine can host multiple VMs. Guest operating systems can be executed on VMs and function as though executing on actual hardware of a physical machine.
A hypervisor or virtual machine manager provides an interface between VMs and the underlying hardware of a physical machine. By multiplexing all accesses to the underlying hardware among various VMs, a hypervisor guarantees various VMs the usage of the actual hardware, such as processors, system memory, etc., of the physical machine.
FIG. 1 depicts a block diagram of a prior art system (100) comprising a server computer (105) having a number of VMs (110, 120 and 130) each associated with a secure function; e.g., a virtual Trusted Platform Module (VTPM) (115, 125 and 135) as specified by the Trusted Computing Group (TCG) wherein trust within a system or trust between a system and another entity is based on a VTPM. The server (105) supports a hypervisor (140), wherein a virtual machine and its associated VTPM is powered-on by the hypervisor (140). The server (105) also comprises an entropy pool (145) comprising the data used in seeding a random number generator associated with each VTPM. The random generator is used for e.g., RSA key generation and nonces for communications. The hypervisor provides an interface between VMs (110, 120 and 130) and the underlying hardware of a physical machine (150), which includes processors (155) and system memory (160).
When a VM is required to start, the hypervisor (140) begins boot of the VM (e.g., a first VM (110)) and its associated VTPM (e.g., a first VTPM (115)). The first VTPM (115) begins its initialization and performs self-test routines (e.g., self-tests of its algorithms, such as, ensuring that it can generate an RSA key) as part of the initialization, reporting the results of its self-tests to its associated first VM (110) at the request of the first VM (110).
With reference to FIG. 2, as part of the first VTPM's (115) self-test, the first VTPM (115) invokes TPM emulation software (200) to self-test. TPM emulation software (200) of the first VTPM (115) executes routines associated with cryptographic support software (205) in order to complete its self-test. Before the cryptographic support software (205) can begin execution, the cryptographic support software (205) must also initialize. As part of the initialization, data from the entropy pool (145) is required to be loaded such that the routines associated with cryptographic support software (205) can be executed. VTPMs require a good quality seed to ensure that the random numbers generated are of high-quality to prevent certain types of attack.
The cryptographic support software (205) makes a request for the data by contacting the hypervisor (140). In response to receiving the request, the hypervisor (140) checks the entropy pool (145) to determine whether the entropy pool (145) contains enough data having a high level of entropy. If the entropy pool (145) does not contain enough data having a high level of entropy, a delay occurs whilst data is gathered to replenish the entropy pool (145). If the entropy pool (145) does contain enough data, the hypervisor (140) returns data to the cryptographic support software (205) such that the data can be used as a seed for a random generator, and the resulting random number can be used for the routines associated with cryptographic support software (205). The cryptographic support software (205) can complete its self-test and control is returned to the TPM emulation software (200) which continues processing—during this processing, the TPM emulation software (200) can make further calls to the cryptographic support software (205) in order to test further cryptographic functions, that is, the TPM emulation software (200) can continue to determine whether it can service (when requested) the first VM (110). Once such processing is complete, the TPM emulation software (200) is operable to record self-test data in an internal status area which can be retrieved when the first VM (110) makes contact. When the components of the first VTPM (115) have finished their self tests, the first VTPM (115) awaits contact from the first VM (110).
It should be understood that if several VMs power-on at once (and thus, if several associated VTPMs also boot at once), each VTPM will need to consume data from the entropy pool. This may starve the entropy pool, resulting in one or more of the VTPMs stalling, waiting for the data to be replenished—this in turn halts the boot of a stalled VTPM's associated VM. As it may take several seconds or even several minutes to replenish the entropy pool, this delay may be unacceptable to enterprises.